mspm0: read_reset_cause() #4831

doxxx · 2025-11-03T20:35:37Z

This adds a read_reset_cause function that returns an enum value derived from the SYSCTL.RSTCAUSE register.

Based on the work by @charlesbmi in #4732.

Example usage code tested on-device:

match embassy_mspm0::read_reset_cause() {
    Ok(cause) => {
        use embassy_mspm0::ResetCause::*;
        let desc = match cause {
            NoReset => "No reset since last read.",
            PorHwFailure => "POR- violation, SHUTDNSTOREx or PMU trim parity fault.",
            PorExternalNrst => "NRST triggered POR (>1s hold).",
            PorSwTriggered => "Software triggered POR.",
            BorSupplyFailure => "BOR0- violation.",
            BorWakeFromShutdown => "SHUTDOWN mode exit.",
            BootrstNonPmuParityFault => "Non-PMU trim parity fault.",
            BootrstClockFault => "Fatal clock failure.",
            BootrstSwTriggered => "Software triggered BOOTRST.",
            BootrstExternalNrst => "NRST triggered BOOTRST (<1s hold).",
            BootWwdt0Violation => "WWDT0 violation.",
            SysrstBslExit => "BSL exit.",
            SysrstBslEntry => "BSL entry.",
            SysrstWwdt1Violation => "WWDT1 violation.",
            SysrstFlashEccError => "Flash uncorrectable ECC error.",
            SysrstCpuLockupViolation => "CPULOCK violation.",
            SysrstDebugTriggered => "Debug triggered SYSRST.",
            SysrstSwTriggered => "Software triggered SYSRST.",
            CpurstDebugTriggered => "Debug triggered CPURST.",
            CpurstSwTriggered => "Software triggered CPURST.",
        };
        uart_log!(logger, 256, "Reset cause: {}", desc);
    },
    Err(code) => {
        uart_log!(logger, 256, "Reset cause: Unknown ({})", code);
    }
}

doxxx · 2025-11-03T20:40:38Z

I don't understand those ci/build failures. This builds just fine locally.

doxxx · 2025-11-03T20:59:35Z

Ah, I see the problem. For some MSPM0 chips the WWDT0 reset cause is a different level, so the generated PAC enum is named differently: BOOTWWDT0 vs SYSWWDT0.

felipebalbi · 2025-11-03T21:00:20Z

Ah, I see the problem. For some MSPM0 chips the WWDT0 reset cause is a different level, so the generated PAC enum is named differently: BOOTWWDT0 vs SYSWWDT0.

Maybe better to patch the PAC in that case?

doxxx · 2025-11-03T21:04:08Z

There's other funny stuff going on with the MSPM0L13xx PAC -- it has WWDT0 and WWDT1 reset causes but there's only one WWDT0 defined for e.g MSPM0L1306... And some of the PAC reset cause values don't line up with the MSPM0 tech reference either.

I'll investigate some more.

embassy-mspm0/src/lib.rs

doxxx · 2025-11-04T15:24:47Z

I couldn't think of a better way to do this. Even if I fixed the reset cause Id enum in the PAC, it still would have a different set of values for the G-series, which would make for a horrific cfg condition to get it right. I thought it would be simpler to hard-code the values according to the tech reference.

i509VCB · 2025-11-04T16:51:04Z

I couldn't think of a better way to do this. Even if I fixed the reset cause Id enum in the PAC, it still would have a different set of values for the G-series, which would make for a horrific cfg condition to get it right. I thought it would be simpler to hard-code the values according to the tech reference.

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

doxxx · 2025-11-04T20:20:24Z

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.

Are you okay with using the hard-coded values instead of the PAC enum values?

i509VCB · 2025-11-04T20:36:32Z

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.

Are you okay with using the hard-coded values instead of the PAC enum values?

Something like

PorHwFailure = pac::ResetCause::PorHwFailure

is fine for enum definitions. But I'm not sure we want to make it repr(u8)

doxxx · 2025-11-04T20:45:36Z

In this case if there are enough differences I would just define 2 enums and pick based on chip family with cfg.

It's one extra enum variant for G-series chips. Everything else is the same as far as I can tell. I can use cfg to make that one enum variant only preset for G series.
Are you okay with using the hard-coded values instead of the PAC enum values?

Something like
PorHwFailure = pac::ResetCause::PorHwFailure
is fine for enum definitions. But I'm not sure we want to make it repr(u8)

Alternatively, we don't define values for ResetCause and just let the compiler generate values. It doesn't look like other enums maintain the underlying register value.

i509VCB · 2025-11-04T21:01:05Z

Alternatively, we don't define values for ResetCause and just let the compiler generate values. It doesn't look like other enums maintain the underlying register value.

That's fine and probably preferable (we don't guarantee ABI stability of values)

doxxx · 2025-11-04T22:42:03Z

Spurious job failure?

i509VCB · 2025-11-04T22:44:11Z

Spurious job failure?

C1104 failed to build. Probably that missing Id field you mentioned?

doxxx · 2025-11-05T00:29:26Z

Spurious job failure?

C1104 failed to build. Probably that missing Id field you mentioned?

Ah crap, yes. I need to figure out how to do a build against every variant to catch that.

doxxx · 2025-11-05T20:22:35Z

This depends on mspm0-rs/mspm0-data#18 to add the missing PAC enum for the C-series but will still need further fixes since there are subtle differences in the PAC enum between series.

i509VCB

Just pending on mspm0-data merge.

doxxx · 2025-11-07T22:32:58Z

Still have to edit this to make two of the variants optional on c110x.

i509VCB · 2025-11-08T00:12:59Z

embassy-mspm0/src/lib.rs

+///
+/// If the reset cause is not recognized, an `Err` containing the raw value is returned.
+#[must_use = "Reading reset cause will clear it"]
+pub fn read_reset_cause() -> Result<ResetCause, u8> {


Last comment is relating to return value. We do exhaustively measure each value hardware can produce, so we could mark other values as unreachable.

unreachable_unchecked is technically valid but would cause undefined behavior when new chips are added and this code isn't updated.

I'd rather err (haha) on the side of caution and keep the Err return to avoid undefined behavior. A runtime panic is better than undefined behavior.

i509VCB

If possible can you squash the commits?

@charlesbmi

This adds a read_reset_cause function that returns an enum value derived from the SYSCTL.RSTCAUSE register. Based on the work by @charlesbmi in embassy-rs#4732.

i509VCB reviewed Nov 4, 2025

View reviewed changes

embassy-mspm0/src/lib.rs Outdated Show resolved Hide resolved

i509VCB approved these changes Nov 7, 2025

View reviewed changes

i509VCB reviewed Nov 8, 2025

View reviewed changes

i509VCB approved these changes Nov 8, 2025

View reviewed changes

mspm0: read_reset_cause()

ef7729e

This adds a read_reset_cause function that returns an enum value derived from the SYSCTL.RSTCAUSE register. Based on the work by @charlesbmi in embassy-rs#4732.

doxxx force-pushed the reset-cause branch from e436c71 to ef7729e Compare November 8, 2025 04:11

i509VCB added this pull request to the merge queue Nov 8, 2025

Merged via the queue into embassy-rs:main with commit e187f43 Nov 8, 2025
8 checks passed

mspm0: read_reset_cause() #4831

mspm0: read_reset_cause() #4831

Conversation

doxxx commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

doxxx commented Nov 3, 2025

Uh oh!

doxxx commented Nov 3, 2025

Uh oh!

felipebalbi commented Nov 3, 2025

Uh oh!

doxxx commented Nov 3, 2025

Uh oh!

Uh oh!

doxxx commented Nov 4, 2025

Uh oh!

i509VCB commented Nov 4, 2025

Uh oh!

doxxx commented Nov 4, 2025

Uh oh!

i509VCB commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

doxxx commented Nov 4, 2025

Uh oh!

i509VCB commented Nov 4, 2025

Uh oh!

doxxx commented Nov 4, 2025

Uh oh!

i509VCB commented Nov 4, 2025

Uh oh!

doxxx commented Nov 5, 2025

Uh oh!

doxxx commented Nov 5, 2025

Uh oh!

i509VCB left a comment

Choose a reason for hiding this comment

Uh oh!

doxxx commented Nov 7, 2025

Uh oh!

i509VCB Nov 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

doxxx Nov 8, 2025

Choose a reason for hiding this comment

Uh oh!

i509VCB left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

doxxx commented Nov 3, 2025 •

edited

Loading

i509VCB commented Nov 4, 2025 •

edited

Loading

i509VCB Nov 8, 2025 •

edited

Loading